データ分析ツールにデータを取り込まずに検索！ - Splunk Federated Search for S3 を使ってみた
2024.10.28データストアは大容量で安価なデータレイクに、分析は必要な時に分析プラットフォームからデータレイクに対して検索をかける、これまでの常識をくつがえすようなソリューションを Splunk で使うことができます。
データは古くなればなるほど、利用頻度は減るケースが一般的です。しかしコンプライアンス要件によって、万が一のときのために利用頻度の低い古いデータであっても、検索できるようにしておく必要があることも少なくありません。
こういった場合、データに対する「利用頻度」、「コスト」、「コンプライアンス要件への準拠」のバランスを取ることが難しくなります。
この機能を使うと、データ分析プラットフォームは分析することに注力し、ストレージ機能は外部に置いておけるようになります。
今回は、そんなコンセプトを実現する、Splunk Federated Search for S3 についてご紹介していこうと思います。
利用ユースケース
- インシデント発生時のフォレンジック調査
- 普段は可視化までする必要はなく、フォレンジック用途として万が一のためのアドホックな検索ができるようにしておく
- 過去のデータに対しての調査・検索
- コンプライアンス監査や過去のデータ分析用途により、通常よりも古いデータが必要となった時に検索ができるようにしておく
- データの探索
- 有効なデータであるかまだ判断されていないデータソースに対して、データの分析価値があるかどうかの探索が行えるようにしておく
苦手なところ
- 非構造化データで複雑なパターンを持っている場合は、ETL処理が必要になってきます。AWS GlueのJobなどを使って変換が必要になってくると少し手間がかかってきそうです
- 頻繁に検索をかけたり、可視化する場合はコストがかさんでしてしまい割高になってしまいます。使い所の見極めが必要です
どのように動くのか
Federated Search for S3 はデータレイクとしてS3へのデータ保存はそのままにして、AWS Glueによるデータカタログを参照し、Splunk から検索する仕組みを取ります。
また、利用にあたっていくつかの必要前提が存在しています。
主な要件は以下ですが、その他細かいものもあるので、利用の際は公式ドキュメントにも目を通しておいてください。
- Splunk Cloud であること
- Splunk Cloud がデプロイされているリージョンとAWS GlueおよびS3のリージョンが同じであること
- DSU (Data Scan Units) のライセンス購入が必要
Federated Search for S3 の設定の流れ
設定の流れは以下のようになります。
- S3内の検索したいデータを特定する
- AWS Glue でデータカタログを作成する
- Federated Providerの作成
- Glue database、S3への権限設定
- Federated Indexの作成
それでは、早速やってみます。
S3内の検索したいデータの特定
これから新しくS3に保存するデータでもいいですし、すでにS3に保存しているデータでも構いません。
Federated Search for S3 で検索するデータを特定します。
今回は、CloudTrailログを対象とします。
すでにCloudTrail証跡の設定は実施できているものとします。
S3の「<バケット名>/AWSLogs/<アカウントID>/CloudTrail/」が対象となるログの基準のパスとなります。
AWS Glue でデータカタログを作成する
次にAWS Glueでデータカタログを作成します。
まず、Databaseを作成します。
次にスキーマ定義をするテーブルを作成します。
テーブルの作成方法は何通りかあります。
AWS GlueのCrawlerから作成、AWS Glueでマニュアルでテーブルを作成、Amazon AthenaのDDLから作成、CloudTrailであればCloudTrailのイベント履歴から作成、AWS Lake Formationから作成などがあります。
ここでは、Amazon AthenaのDDLを使って作成することにします。
Amazon Athenaのクエリエディタを開きます。
CloudTrailのスキーマはこちらで参照することできるので、コピーして貼り付けます。
※S3のロケーションは読みかえる必要がありますので、ご自身の環境に合わせて書き換えます。
再度、AWS Glueの画面に戻ると、テーブルが作成されていることが確認できます。
Federated Providerの作成
次にSplunk Cloud側のコンソールでFederated Providerを作成します。
設定の統合サーチで、Add federated providersをします。
- Federated provider name: 好きな名前
- AWS account id: 検索するS3データのアカウント
- Glue data catalog database: 先ほど作成したGlueデータベース
- Glue Data Catalog tables: 先ほど作成Glueテーブル
- Amazon S3 locations: S3のスキャンする位置
Generate policyをクリックすると、Splunk Cloudからアクセスするためのポリシーが表示されます。
これをそれぞれ、AWSに設定していきます。
Glue data catalog resource policy は、AWS GlueのCatalog settingsに設定していきます。
Amazon S3 backet policy は、Amazon S3の検索対象となるS3バケットのバケットポリシーに設定します。
バケットポリシーは既存の設定が入っている場合は、該当部分を最後に追記します。
再度、Splunk Cloudの画面に戻って、同意にチェックして、Create providerを行います。
その際、エラーが発生するので、Update Amazon S3 permissions を押します。
ここで、チェックが失敗していた場合は、権限設定などでおかしいところがある可能性があるので、見直してみてください。
Federated Indexの作成
最後に、そのままSplunk Cloudの画面で、Federated Indexを作成します。
- Federated index name: 好きな名前
- Federated provider: 先ほど作ったprovider
- Remote dataset: dataset nameにAWS Glueのテーブルを選択
- Time settings not required: チェックつけない（タイムスタンプを持っていないデータであればチェックをつける）
- Time field: ログのタイムスタンプを表すフィールド（CloudTrailの場合、
eventtime） - 時間フォーマット: Time fieldのフォーマットをSplunkのタイムフォーマットに合わせる（今回は
%Y-%m-%dT%H:%M:%SZ） - Unix time field:
_timeを指定する（こうすることで、timechartなどが使えるようになる※参考）
保存をします。
これで設定が完了しました。
検索してみる
検索してみます。
必ず「|」からはじまり、sdselect というサーチコマンドを使います。
通常のSPLと若干異なり、SQLベースの検索文になります。
| sdselect * from federated:fd-test-index
JSON構造が入れ子になっている場合は、ドットで区切ることでネストしたフィールドを指定できます。
| sdselect * from federated:fd-test-index where userIdentity.type="AssumedRole"
Indexで設定した、_time を使うことでtimechartコマンドを使うことができます。その際、sdselect コマンドの列指定に _time を指定する必要があります。
timechart ではフィールド名が type になっていたりして少し癖があります。
| sdselect _time, userIdentity.type from federated:fd-test-index
| timechart count by type
視覚エフェクトを使って、グラフ化することも可能です。（一応、ダッシュボードに登録することも可能です。）
まとめ
Splunk の Federated Search for S3 を試してみました。
検索スピードは思った以上に速い印象で、利用に関しては全く問題がないように思いました。
ドキュメントの参考でも、1TB容量をスキャンする場合10秒程度がかかるようですので、通常のスキャン量であれば問題ないスピードで検索可能かと思います。
利用頻度が多くないデータや、古くなったデータ、大容量で取り込むにはコスト上難しいデータなど、様々なケースで利用することができそうです。
